1. Field of the Invention
The present invention relates generally to the field of communications networks and, more specifically, to standard identification communications between telecommunications nodes.
2. Description of the Related Art
A communications network typically comprises a plurality of communications nodes, which “speak” to each other by exchanging various classes of messages, representing commands, data, requests, replies, notifications or others, according to the technology and protocol used within each such network. For meaningful communications to take place between communications nodes, the message syntax and semantics must be understood and agreed among the communicating nodes. The document that specifies the syntax and semantics of the messages exchanged between nodes is sometimes called the interface specification, technical specification or protocol. At the operation level, the Integration Reference Point (IRP) is one of such protocols, through which the communications messages are exchanged between nodes in a management system. There are many types of IRP specifications or protocols, such as for example for fault management (Alarm IRP) and for configuration management (Basic Configuration IRP).
In 3rd Generation Partnership Project (3GPP) based communications environments, the IRP specifications define and control network management-related communications between an Element Management-Network Management node (EM-NM) and the controlled Network Elements nodes (NEs).
Various IRP specifications exist for defining communications in a plurality of network management sub-fields. In the fault/alarm management field, one of the most basic needs is to support alarm surveillance. Product specific applications use the Alarm IRP specification to be able to forward alarm notifications from various NEs and to a Fault Monitoring (FM) application. Another IRP specification is the Basic Configuration Management IRP specification that defines and controls the management of topology and logical resources in the managed network (retrieval of the configuration and status of the network elements). Finally, the Performance Monitoring (PM) is achieved according to the Performance Data IRP specification.
Reference is now made to FIG. 1.a (Prior Art), which shows a nodal operation and signal flow diagram of a typical prior art scenario for exchanging IRP specification names between two communications nodes. In FIG. 1.a, a management system 100 comprises an IRP Manager 102 that communicates with an IRP Agent 104. For this purpose, the Manager 102 must first know the supported IRP specification and version used and supported by the IRP Agent 104. Each type of IRP specification defines a mandatory method called getXXXIRPVersion( ), wherein “XXX” refers to the given type of IRP specification. For example, the method getAlarmIRPVersion( ) is used for deducting the Alarm IRP specification supported by a given node. With reference to FIG. 1.a (Prior Art), prior to any further communications, the IRP Manager 102 transmits a getXXXIRPVersion request message 106 to Agent 104 for inquiring of the Agent's supported IRP specification version, to which the Agent 104 replies with a getXXXIRPVersion reply message 108 comprising a parameter 110 indicative of a list of elements, each containing the name and the version number the Agent's supported IRP specifications. In current implementation, an element of the parameter 110 consists of three characters, such as for example “1f1”.
Reference is now made to FIG. 1.b (Prior Art), which shown a schematic representation of the structure of one element 120 of the parameter 110 returned in the message 108 shown in FIG. 1.a. The element 120 consists of three segments 122, 124 and 126, wherein the first segment 122 refers to the IRP IS version number (which represent the version number of the IRP Information Service), the second segment 124 refers to the type of IRP specification type, and the third segment refers to the IRP SS version number (which represent the version number of the IRP Solution Set). For example, the string “1f1” means that the Agent 104 (shown in FIG. 1.a) implements the IRP IS version number 1 of the (“f”, Fault) Alarm IRP specification, IRP SS version number 1.
There are three problems with the above way of handling and transmitting the IRP specification name and version. The first problem is that the IRP specifications evolve through the acceptance by the standard body of multiple technical specification Change Requests (CRs) made by industry players. CRs writers do not always take into account if their proposed changes affect the IRP version number or not. CR writers typically do not suggest to change the constant strings representing the notification categories in the NotificationIRPConstDefs IDL file, an Interface Description Language (IDL). Referring to FIG. 1.a, the notification categories are represented by the parameter 110 comprised in message 108. If the constant strings representing the notification categories are not adequately changed in the NotificationIRPConstDefs IDL file (not shown in FIG. 1.a; information from the IDL file defines the IRP type and version number, and is compiled by the Agent for the generation of the appropriate parameter 110) as and when required by CRs, which oftentimes occurs nowadays, IRP Manager 102 may be given the erroneous IRP version supported by the Agent 104.
The second problem is the lack of clear understanding of the standard body members on how to handle multiple CRs, where some CRs affect backward compatibility while others do not. By not considering that some CRs affect backward compatibility or by processing CRs in the wrong order, the process may end-up by having wrong values for constant strings representing the notification categories, such as the values sent in parameter 110 of FIG. 1.a. 
Finally, the third problem is that whenever a version number of any IRP specification is changed, it also requires a new version number for the given Notification IRP specification, since all the constant strings representing the notification categories are defined in a NotificationIRPConstDefs IDL file, which is included in a Notification IRP SS document. Consistent reviews of all IRP specifications impacted by an accepted CR are not always performed by the standard body, which sometimes creates transmission confusion and errors between interconnected nodes implementing signalling based upon the given IRP specification.
Accordingly, it should be readily appreciated that in order to overcome the deficiencies and shortcomings of the existing solutions, it would be advantageous to have a scheme that unequivocally identifies a technical specification (protocol) used by co-operating nodes. The present invention provides such a solution.